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HET GENOOTSCHAP 


Deverenigingsteltzich ten doel het wetenschappelijk onderzoek op het 
gebied van de elektronica en de informatietransmissie en verwerking 


te bevorderen en de verbreiding en toepassing van de verworven ken- 
nis te stimuleren. 
Het genootschap is lid van de Convention of National Societies of 


Ir. 0.B.M. Pietersen 
Ir. P.P.M. van der Zalm 


Voor lidmaatschap wende men zich tot de secretaris. 
‘Het lidmaatschap staat open voor academisch gegradueerden en hen, 


lidmaatschap mogelijk maakt. De contributie bedraagt f 60, — per jaar. 
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tie wordt verleend op de contributie. Op aanvraag kan deze reductie 

‘ook aan anderen worden verleend. 


HET TIJDSCHRIFT 


Het tijdschrift verschijnt zesmaal per jaar. Opgenomen worden artike 
len op het gebied van de elektronica en van de telecommunicatie, 
Auteurs die publicatie van hun wetenschappelijk werk in het tijd 
‘schrift wensen, wordt verzocht in een vroeg stadium contact op te ne- 
men met de voorzitter van de redactiecommissie, 
De teksten moeten, getypt op door de redactie verstrekte tekst- 


_De abonnementsprijs van het tijdschrift bedraagt f 60,—. Aan le- 
den wordt het tijdschrift kosteloos toegestuurd. 

‘Tarieven en verdere inlichtingen over advertenties worden op aan- 
vrage verstrekt door de voorzitter van de redactiecommissie. 
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PARALLEL COMPUTING AT PHILIPS: 
The Object-Oriented Approach 


Ir. Hans Oerlemans, Ir. Eddy Odijk, Wim Bronnenberg 
Philips Research Laboratories Eindhoven 


Symbolic applications pose challenging requirements on parallel computer architectures and the design 
and expression of parallel algorithms. In this paper, an object-oriented approach, to meet these re- 
quirements is described. It treats the research and design performed at Philips Research Laboratories 
Eindhoven in the framework of the current parallel processing projects. In the Parallel Object-Oriented 
Language POOL, a program is subdivided into a large number of so-called objects, which communi- 
cate by sending messages. The language offers explicit parallelism and support for structuring large 
applications to be executed on POOMA, the Parallel Object-Oriented MAchine. The POOMA archi 
tecture consists of a collection of self contained computers, comprising a CPU, local memory and a 
communication unit to connect these computers via a point-to-point packet switching network. 


1 Introduction e DOOM (Decentralized Object-Oriented 
Machine), [Bronnen87] 

While many of the efforts in parallel computers for In DOOM an effort into the construction of a 

numeric purposes emphasize compatibility with ex- general purpose parallel programming system is 

isting programming languages, new ways have to be being undertaken. DOOM is executed as sub- 

followed for symbolic parallel computers. project A of Esprit project 415. 


In a language-first approach, a number of choices 
can be made when it comes to programming such 
systems. For instance, the models of functional and 
logic programming allow parallel execution, where, 
in principle, the parallelism is invisible to the pro- 
grammer and is extracted by the implementation 
(implicit parallelism). 

Central themes in parallel computer architec- 
ture are formed by the communication structure and 
processor support for new language features. For 


PRISMA (Parallel Inference and Storage MA- 
chine), [Apers88] The main aim of PRISMA is 
to adopt parallel object-oriented programming 
techniques for the construction of applications 
manipulating large data and knowledge bases. 
PRISMA is partially supported by the Dutch 
”Stimuleringsprojectteam Informaticaonderzoek” 
(SPIN). 


TROPICS (TRansparent Object-oriented Par- 


example, several shared memory systems have been allel Information Computing System) 

proposed with busses or multi-staged switching net- TROPIGS is a joint effort of four major com- 

works as communication means. puter manufacturers (Philips, Nixdorf, Olivetti, 
This paper presents a survey of a different ap- Thomson) to introduce parallel object oriented 

proach to parallel computing: an object-oriented ap- systems as the basic platform into the office au- 

proach. It presents the concepts of the Parallel Object- tomation environment. The TROPICS project 

Oriented Language POOL and a highly parallel, is supported by Esprit (project 2427). 


general purpose computer system for execution of 
programs in this language: the Parallel Object-Orien- 
ted MAchine, POOMA. In POOL, a program is 


The main issues to be addressed in these projects, 
cover a wide spectrum to obtain a well balanced de- 


subdivided into a large number of so-called objects, Ek 

which communicate by sending messages. The POO- e The construction of prototypes of the Paral- 

MA architecture contains many identical computers lel Object-Oriented MAchine, POOMA, con- 

that are connected by means of a packet-switching sisting of identical self-contained computers, each 
network. Each computer supports the execution of having a CPU, local memory, disc and commu- 

a number of POOL-objects. nications means, which are connected in a di- 

The approach described here, forms the ba- rect packet-switching network. Each computer, 

sis of a number of parallel processing projects being called a node of the system, has a copy of the op- 

undertaken at Philips Research Laboratories Eind- erating system kernel. This kernel performs lo- 

hoven. These projects are: cal resource management, and cooperates with 
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the other kernels for global operating system 
tasks. For DOOM and PRISMA prototypes 
containing some 10 nodes are realized, for TROP- 
ICS prototypes containing 100 nodes are under 
construction. 

The prototype systems are all connected, as a 
satellite, to a host computer, where the pro- 
gramming environment resides. This setup was 
chosen for the prototypes to postpone the pro- 
gramming effort on an environment, to a devel- 
opment stage. 


A parallel object-oriented language, POOL, in 
which significant application programs can be 
programmed. The language provides the user 
with control of parallelism and granularity. It is 
important for the language to have clear seman- 
tics. Support for the verification of programs is 
desirable, and becomes even more important in 
a parallel environment. The design of a proof 
system forms therefore part of the effort. 


Construction of applications in the area of sym- 
bolic processing that assess the potentials of 
POOL and the POOMA system architecture. 
The first of these is a parallel database man- 
agement system. The second is a parallel ver- 
sion of the analytical component of the Rosetta 
natural language translation system [Landsb87). 
Rosetta is currently being designed in the same 
department at Philips Research. 

In the framework of TROPICS a multimedia 
document systems and a carthographic database 
systems are being developed. 

While our emphasis is on symbolic processing, 
the VLSI circuit simulator of AEG [Mehring87] 
and applications designed by others will demon- 
strate the applicability of POOMA for numeri- 
cal applications. 


From the above it follows that the new issues for the 
design of programming languages, application pro- 
grams and computer systems, raised by the quest 
for massive parallelism, are approached in an integral 
and coherent manner. In our view this is essential to 
successfully address all of the above issues. 


2 The programming language POOL 


POOL is an acronym for “Parallel Object-Oriented 
Language”, and denotes a family of languages de- 
signed in the course of the parallel processing projects 
at Philips Research. 

The effort in language design was directed at 
a language that exploits the ideas of object-oriented 
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programming in order to make the programming of 
systems with a large amount of parallelism feasi- 
ble. It was not meant as a tool for rapid prototyp- 
ing (where the excellence of many existing object- 
oriented languages lies), but as a language to pro- 
gram large, well-designed systems, with as many fa- 
cilities for static checking as possible. 


2.1 Introduction to POOL 


The essence of object-oriented programming is the 
subdivision of a system into objects, which are inte- 
grated units of data and procedures. Objects are en- 
tities of a very dynamic nature: they can be created 
dynamically, the data they contain can be modified 
and they even have an internal activity of their own, 
as will be described later. 

The most important property of objects is that 
they form the units of abstraction and protection. 
An object can have variables (also called instance 
variables) to store its internal data in. A variable 
can contain (a reference to) an object. Changing 
(assigning to) a variable causes it to refer to a dif- 
ferent object than before. The variables of an object 
cannot be accessed directly by other objects: there is 
a a clear separation between the inside and outside 
of an object. 

Objects may only interact by sending messages 
to each other. Each object states explicitly to which 
object it sends a certain message. Upon accepting 
a message, the object will execute one of its proce- 
dures (indicated by the sender) and the object that 
is the result of this execution will be sent back to 
the sender. In object-oriented languages such a pro- 
cedure is called a method. Note that the method 
executed by the object can access its variables. As 
the object has explicit control of its interaction with 
other objects, it can keep its internal data in a con- 
sistent state. 

Objects are entities of a semantic nature. On 
the syntactic level the corresponding notion is that of 
a class. A class is a description of the behaviour of a 
set of objects, its instances. It describes the number 
and kind of their variables, and the methods that are 
executed in response to messages. A number of so- 
called standard classes (e.g, Integer and Character) 
are already predefined. 

Beside the methods attached to each instance 
of a class, there are also routines: procedures that 
are related to a class rather than to a specific object. 
They can be called by all instances of all classes in 
a program. A typical task for a routine is to create 
and initialize new objects of its class. 

POOL has a strong typing mechanism: with 
each variable a class is associated (its type); it may 
contain references to objects of that class only. With 


every expression in the language, a class ( again 
called its type) can be associated statically. A pro- 
gram is only considered valid if for every expression 
its type is the same as required by its context. Thus, 
many programming errors can be detected before the 
program is executed. 


2.2 Parallelism in POOL 


There are several ways to combine object-oriented 
languages with parallelism. In Smalltalk-80, 
[Goldberg83] the traditional concept of a process is 
introduced, where several of these may execute in 
parallel, each acting in the same way as if it were 
an ordinary sequential object-oriented program. The 
same additional constructs are necessary as with tra- 
ditional processes to get the concurrency under con- 
trol. For example, in Smalltalk-80, synchronization 
and mutual exclusion is done by semaphores. 

A better approach to integration starts by as- 
sociating a process with every object. By doing this, 
we also get a very natural model for a purely sequen- 
tial execution, in which at any time only one object 
is active, by adhering to the following restrictions: 
(1) execution starts with only one active object, (2) 
the sender of a message always waits until the corre- 
sponding method has returned its result and (3) an 
object is only active when executing methods. 

Starting from such a sequential execution there 
are several possibilities to allow genuine parallelism, 
each one characterized by which of the above restric- 
tions is relaxed: 

(1) By allowing to start execution with several active 
objects, we obtain a static amount of parallelism. 
(2) If we allow the sender of a message to go on with 
its own activities without waiting for the result of the 
method, the receiver can start executing in parallel 
with the sender asynchronous message passing. By 
creating more objects and sending them messages, 
the number of concurrently active processes can be 
increased quickly. This principle is employed, for 
example, in the actor languages developed at MIT 
[Hewitt77]. (3) Another possibility is to specify for 
each object a body, an activity of its own, which it 
executes without the need for a message to initiate 
it. In this case the moments when the object is will- 
ing to accept, or answer a message must be indicated 
explicitly. By selectively indicating which methods 
it is willing to execute, an object can get complete 
control over the consistency of its data. Because ob- 
jects have a body, the concurrency need not come 
from the concurrent execution of a message sender 
and the processing of the message by the receiver, so 
in this situation synchronous message passing would 
be sufficient. 

POOL offers both synchronous and asynchro- 


nous communication as well as the possibility to start 
execution with several active objects. A rationale for 
this and other choices has been presented in [America87). 


2.3 Resulting characteristics of POOL 


The object-oriented approach acknowledges the fact 
that the programmer is responsible for and has the 
best knowledge of the detection and use of paral- 
lelism in his application. To relieve his task, object- 
oriented languages supply the user with a natural 
method for structuring and partitioning combined 
with a message-passing mechanism for communica- 
tion and synchronization. 

In POOL every data item, from a boolean to a 
complete database, is represented by an object. All 
these objects have the same general way of interact- 
ing with each other. An important benefit of this 
unification is the resulting simplification in the lan- 
guage. 

The dynamic structures exhibited by many sym- 
bolic applications, for which the fifth generation par- 
allel architectures are targeted, are matched in object- 
oriented languages by the mechanisms for dynamic 
creation of objects and for communication to other 
objects. 

The subdivision of a system into objects yields 
coinciding notions for both information hiding and 
protection (essential for reliable and maintainable 
software) and concurrent execution. Security is fur- 
ther enhanced by the strong typing mechanism. A 
unit mechanism, not described here, is an impor- 
tant feature to further enhance abstraction and to 
improve reusability of program parts [America88), 
[America88a). 


3 The POOMA system 


POOMA is an experimental system in which the ex- 
ploration of parallelism in object-oriented program- 
ming and the principles of efficient implementations 
are investigated. 

We start describing the implementation by hav- 
ing a closer look at the computational model of POOL. 
As has been shown in the previous section, a POOL 
program in execution consists of processes (objects) 
which internally show sequential control-flow, or im- 
perative, behaviour. These processes can be dy- 
namically created during program execution upon 
request by other objects. Explicit deletion of ob- 
jects is not possible. Communication and synchro- 
nization between objects in POOL are performed by 
(a)synchronous message passing. A sender can only 
send messages to objects to which it has a reference 
in one of its variables. If more than one message is 


sent to an object (by different sending objects), the 
first received message corresponding to a method in 
the answer statement will be invoked. 

Obviously, this computational model does not 
incorporate any notion of sharing data. In the ex- 
treme, one could envisage an implementation con- 
sisting of a large number of self-contained comput- 
ers, ie consisting of a processor and local memory, 
each of which executes a single object. The comput- 
ers would then be connected through some, virtu- 
ally fully connected, network that passes messages 
between objects. Although such an implementation 
is not realistic in terms of cost-performance, it pro- 
vides an interesting abstract machine model. Us- 
ing such an Abstract POOL Machine (APM) model, 
one can show the various system components and de- 
sign decisions that are required to map the dynamic, 
and changing, graph of communicating objects onto 


a static graph of POOMA nodes. The mapping of. 


processes occurs dynamically, and the communica- 
tion can take place between objects anywhere in the 
system, allowing a many-to-one communication pat- 
tern. 

The POOMA system architecture maintains 
the concept of self-contained computers, connected 
by a network. It can be considered as a restricted 
version of the APM sketched above. In the sequel 
the present prototype architecture and the operating 
system for POOMA will be described. The ”design 
space” and required manpower have been restricted 
to the essence of the project goals and a manageable 
size. Therefore, a number of issues is excluded from 
the first design. The system design was focussed at 
the two basic aspects of architectural support: the 
object execution within a node, and the communica- 
tion between nodes. 


3.1 The POOMA architecture 


In this section the architecture of aà POOMA node 
is presented, followed by an introduction of the net- 
work structure that connects these nodes. A node in 
the prototype system basically contains a data pro- 
cessor, a memory subsystem, and a communication 
processor. 

The data processor (DP) executes the code of 
the objects which reside on the node. Unlike a node 
in the APM, a POOMA node is able to execute 
many (presumably some 10 to 1000) objects. The 
processor architecture must therefore support multi- 
processing. Efficient process switching is a first re- 
quirement. Most presently available microprocessors 
are designed to support processes of coarse granular- 
ity and have not been optimized towards this aspect. 
For the prototype system, where the Motorola 68020 
and SPARC microprocessors will be used, this may 
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lead to some performance degradation. 

In an accompanying study, we have shown that feed- 
ing independent instruction streams through a pipe- 
lined processor implementation, is in harmony with 
the POOMA and RISC concepts and removes by- 
passes and interlocks from the implementation, see 
[Bronnen86). 

The memory must host the operating system 
and accommodate for the code, the stacks and the 
message queues of the residing objects. As will dis- 
cussed in the section on the OS, a paged virtual mem- 
ory scheme has been adopted to support memory 
management. 

The last component is the communication pro- 
cessor. In order to avoid that interprocessor com- 
munication becomes the new bottleneck in parallel 
systems, hardware support is appropriate. We have 
taken it to the point where data packets (of fixed 256 
bit size), after transfer by the DP to the local CP, 
are injected by that CP into the network, passed on 
by other CPs to the destination node and are handed 
over to the DP there. Unlike with cut-through rout- 
ing, packets are buffered as a whole before they are 
passed on by a CP. The design of the CP is such 
that it guarantees deadlock and starvation free rout- 
ing of packets, independently of network topology or 
size. Furthermore it incorporates free routing, i.e. 
packets may be forwarded to the same destination 
via different routes while maintaining efficient usage 
and administration of buffer space. The algorithm 
used in the POOMA CP for this purpose, is called 
class climbing [Annot87), 

The routing facility offered by the CP provides 
a powerful and efficient mechanism for higher layers 
of the system, and avoids interruption of the inter- 
mediate DPs. A set of (FIFO) buffers in between CP 
and DP serve the purpose of decoupling the produc- 
tion and the consumption rates of messages in both 
directions. 

Our main goal is to develop, for reasons of cost 
and performance, a one chip VLSI implementation. 
Simulated performance of an implementation with 4 
bidirectional links, used in a network with average 
distance of 4, is 75000 packets/s which is very close 
to the available bandwidth at a 20Mb/s data-rate. 
Currently working is an implementation of the CP 
using commercial available components. Its perfor- 
mance is 50000 packets/sec. This breadboard CP is 
used in our prototypes. 

Another concern of the architecture is the de- 
sign of a topology for the communication network 
[Odijk87). For the topology many candidates with 
different characteristics exist. In general purpose 
machines one prefers one that suits the general case 
where the communication patterns are of an irregu- 
lar nature and may vary during execution. 


Given a maximum number of links (the degree 
of a network) that can be afforded with the imple- 
mentations’ technology, criteria for selection are ob- 
tained by the diameter and the regularity of the net- 
work, the extensibility and its tolerance to defective 
nodes or links. Further criteria may be derived from 
the number of alternative paths between nodes and 
the ease of routing or from physical properties of the 
links, such as the width and transmission speed. 

The main interests in the POOMA design were 
to find a good ratio between the number of links and 
the diameter and have a high degree of regularity. 
Considering the importance of regularity of the net- 
work, we have proposed to build networks as carte- 
sian products (cubes) with optimal chordal rings as 
the elementary building blocks. The resulting gener- 
alized chordal ring cubes yield a lower degree and di- 
ameter than toruses and hypercubes and have excel- 
lent fault tolerance properties. The choice of the ex- 
act topology for POOMA can be postponed, thanks 
to the flexibility of the communication processor. 


3.2 The POOMA Operating System 


The main target for the OS of the POOMA pro- 
totype is: efficient execution of POOL programs. 
Therefore facilities one also needs like a program- 
ming environment, etc. are not offered by the POO- 
MA OS itself, but by the OS of the host computer 
that POOMA is connected to. 

The remaining task of the OS deals with sev- 
eral aspects, such as (local and global) resource man- 
agement, process management and communication 
handling. The latter is described in [Haan88). A 
number of these issues that are kind of special for 
the POOL environment, is described below. 


Allocation of objects onto nodes 

In general, when an object is created, the object 
should be “added” to a node where other objects 
already reside. The selection of the node must be 
done dynamically, due to the creation of objects dur- 
ing program execution, and should aim at an optimal 
use of resources. Conflicting criteria are: 1) proces- 
sor load, 2) memory occupation, and 3) communi- 
cation load. According to the first, objects which 
can operate in parallel should be placed on differ- 
ent nodes. The third leads to keeping objects on the 
same node when they are interacting. 

POOL programs can be annotated with prag- 
mas indicating a set of nodes from which the OS 
can choose for allocation. On basis of this informa- 
tion and by means of the gathered load balancing 
information indicated above, a ” proposed allocation 
node” is calculated. A request for allocation is then 
sent to that node, together with some information 


about the object to be created (eg, its code-size). 
If the request is not accepted, the OS has to calcu- 
late a next candidate. 


Garbage Collection 

In POOL, objects are never destroyed explicitly. How- 
ever, when an object is only waiting for messages or 
its own activity has terminated, and furthermore no 
other object in the system has a reference to it, then 
it may be safely removed from the system. Because 
of the possibly cyclic reference structure, the basic 
garbage collection algorithm (GC) that is needed 
should be Mark and Sweep. For a proper working 
of the GC it is necessary that references to objects 
(eg. in variables) are traceable. There are several 
ways to accomplish this. One way is by means of 
a tagged memory, another way is using two stacks 
per object: one for references to objects and one for 
other data. 


Most traditional mark and sweep garbage col- 
lectors assume that no other processing is going on 
during a GC-phase. This is not acceptable for a 
multi-processor system, because at each moment only 
a fraction of the processors will be actually involved 
in GC and most processors would thus be idle. How- 
ever, special care has to be taken in order to let GC 
go on in parallel with other processing. A special 
synchronization problem that comes up in a decen- 
tralized or distributed system is how to detect that a 
mark phase or sweep phase can start or has finished, 
A more detailed description can be found in [Aug87]. 


Memory management 

The memory of a POOMA node will be used to store 
three different types of items: 

Stacks: for each object residing on the node a dy- 
namically extending and shrinking stack is needed. 
Message queues: for each method of each object re- 
siding on the node a dynamically extending and shrink- 
ing FIFO message queue is needed. 

Code blocks: in principle one code block per object is 
needed. However objects of the same class will share 
code blocks. 

Obviously, these types of items exhibit quite different 
logical behaviours. More, their sizes differ and vary 
per object. Therefore a static split-up of a node’s 
memory is out of the question. 

For POOMA a two level memory management 
system has been designed, with a hardware supported 
paging system as the lower level. This paging sys- 
tem will not be used for extending the memory by 
means of a background store (like in most operating 
systems), but solely to obtain the desired flexibility 
of dynamic allocation of storage blocks. It supports 
the OS with sufficient virtually contiguous memory 
space which is split up in fixed size segments. In 
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this way, e.g., one segment can be reserved per data- 
stack. Increases and decreases in stack size, requir- 
ing allocation and deallocation of (physical) page- 
frames can then be handled independently from the 
behaviour of other segments. 


3.3 State of affairs 


Various prototypes have been realized. Based on the 
following node architecture: 

A processor-memory subsystem being composed of 
a PG2100 processor board, [PG2100] plus an extra 
12 MByte memory extension board. The PG2100 is 
based on the Motorola 68020 microprocessor and has 
an accompanying memory management unit (68851) 
and floating point unit (68881). Furthermore 4 Mbyte 
of on board memory; together with the memory ex- 
tension board each node is equipped with 16 Mbyte. 
In its prototype version (bread-boarded) the commu- 
nication processor takes two (extended double Euro) 
boards. Each node thus consists of 4 boards. 

For DOOM a prototype consisting of 12 nodes 
according to the above architecture has been real- 
ized. It supports a prototype implementation of 
POOL?2, [America88). 

For PRISMA a prototype consisting of 8 nodes 
has been realized. Each node consists of the compo- 
nents described above plus a 100 MByte disc (for 
supporting the database application). It supports a 
prototype implementation of POOL-X, [America88a). 

For TROPICS a number of prototypes are en- 

visaged. A first prototype has been realized that 
consists of 100 nodes according to the above de- 
scription and extended with 50 discs of 300 MByte 
each. For experimental purposes this prototype is 
also equipped with a component that allows the topol- 
ogy of the network to be changed under software con- 
trol. This allows for easy and flexible experimenting 
with different network configurations. 
A second prototype will be based on the SPARC 
microprocessor. It will be equipped with some 32 
MByte of main memory per node and 50 discs. For 
the communication processor a VLSI relisation will 
be used. Using this technology the number of boards 
for each processing node will be reduced to one. 

To allow the application programmers to ob- 
tain experience with the POOL language, implemen- 
tations for executing POOL on sequential systems 
have been realized (an interpreter and a compiler 
plus run-time system running on SUN - UNIX). The 
interpreter package incorporates a tracing and de- 
bugging environment. A third package, emulates the 
the POOMA execution of POOL programs on the 
sequential (SUN - UNIX) system. This interpreter 
configures a network of POOMA nodes, according to 
user specification, and executes POOL programs on 
this network, while administering progress. Costs of 
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instruction execution and communication have been 
derived from the actual POOMA design. Using the 
latter package, characteristics are being measured of 
early versions of the applications mentioned in the 
introduction. 
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NEDERLANDS ELEKTRONICA- EN RADIOGENOOTSCHAP 
(G65ste werkvergadering) 


UITNODIGING 
voor een lezingenavond op dinsdag 31 januari 1989 in het 3e hoofdgebouw 
van de N.V. Nederlandse Spoorwegen te Utrecht. 
THEMA: TELEKOMMUNIKATIE BĲ DE NEDERLANDSE SPOORWEGEN. 
PROGRAMMA 


vanaf 19.45 uur Koffie. 


19.50-20.00 uur Ontvangst door IR. P. F. A. M. OTTEN, Chef Afdeling Elektrotechniek, 
Dienst van Infrastruktuur. 


20.00-20.45 uur IR. A. V. P. VAN DER LINDEN, ontwikkeling en beleid telematika: 
VERNIEUWING VAN DE TELEKOMMUNIKATIE-INFRASTRUKTUUR 
VAN DE NEDERLANDSE SPOORWEGEN. 


20.45-21.00 uur _Videofilm: ELEKTROTECHNIEK ACHTER HET SPOOR. 


2100-2145 uur IR. R. S, DE HAAS, chef sektor ontwikkeling elektrotechniek: 
NIEUWE TELEMATIKA-TOEPASSINGEN BĲ DE NS. 


2145-2200 uur _Diskussie. 


Aanmelding voor de lezingenavond dient te geschieden vóór 23 januari 1989 door middel van 
de aangehechte kaart, gefrankeerd met een postzegel van 55 cent. Niet leden dienen een entree- 
prijs van f 15,00 te betalen. 


Het 3e hoofdgebouw van de NS ligt aan de stadszijde van het station Utrecht CS op loopafstand. 
U loopt vanuit de stationshal naar het streekbusstation en volgt dan het railspoor van de sneltram 
tot het einde . De zijingang van het 3e hoofdgebouw (groot donker bakstenen gebouw) bevindt 
zich dan schuin links voor u. 


Namens het NERG bestuur, 
Ir. N. H. G. Baken, 
Voorburg. januari 1989. Tel. 070 - 436482. 


VISUALIZATION OF 3-D EMPIRICAL DATA: THE VOXEL PROCESSOR 


ir. Peter LJ. van Lieshout, ir. Wim Huiskamp 
TNO Physics and Electronics Laboratory, P.O. box 96864, 2509 JG The Hague, The Netherlands 


Image processing is one of the areas which are known to be very computational intensive. To achieve interactive response of 


imageprocessing systems usually dedicated systems or (mini-) supercomputers are necessary. Imageprocessing is also an area in which the 


application of parallelism is very suitable, because ofthe large amounts of (similar) data involved. In this particular case, 3-D images (images 

in ‘voxel space’) have to be processed interactively. Operations on the voxel space involve 3-D image processing algorithms and 

visualization of the data from arbitrary viewing angles, and with several options for the type of rendering. This paper describes an alternative 
for special hardware or supercomputers for a voxel processor, based on a network of INMOS T800 Transputers. 


Introduction 

The TNO Physics and Electronics Laboratory (TNO-FEL) in the Hague is a 
part of the TNO Division of National Defence Research (TNO-HDO). 

The activities of TNO- FEL focus primarily on operational research, informa- 
tion processing, communication and sensor systems. To support the fast 
data-processing usually required in sensor systems applications, research 
was started into parallel processing techniques. This research has now 
resulted in three major application areas : radar data processing, real-time 
computer generated imagery and 3D image analysis, processing and 
visualization. 3D image processing and visualization is the subject of this 
paper. With the growing availability of 3D scanning devices, the need for high 
performance processing and display systems increased significantly. The 
development of an experimental parallel processing system is described for 
the visualization of three dimensional voxel based images. The aim is the 
visualization of the (unknown) object in such a way that ts spatial structure 
can be understood. An additional demand is that the system istastenough to 
be used interactively. Because of the large number of voxels involved, a 
considerable processing capacity is required. Processing the data in parallel 
‘on a network of Transputers provides the necessary computing power. The 
volume data may be visualized in several ways, involving operations like 
object transformation, hidden-surface removal, depth-shading and cross- 
sectioning. The main advantages of the proposed architecture over dedi- 
cated hardware solutions are: 

- cost/performance ratio 

= flexibility 

-expandabilty 


The Voxel space 

Volume images are normally represented as a series of parallel two 
dimensional slices. These slices may have been obtained from several 
possible sensor systems, examples are Computer 

Tomographic-(CT), Nuclear Magnetic Resonance- (NMR), Ultra Sounding or 
Optical- (LASER) scanners. Voxel representations are very suitable for 
applications with 3D empirical data. However synthetic data may also be 
used, examples are: solid modeling and fluid dynamics simulations. Before 
volume rendering became feasible, experts had to interpret every single slice 
to deduce the 3D information. Until recently, computer assisted techniques to 
visualize the volumes were based on displaying contours only, because ofthe 
processing time involved. These contours often had to be traced manually 
from the actual data. Full use of the 3D data could only be made through 
off-line computing. 


Several architectures based on dedicated hardware have been proposed to 
increase performance (Ref. 1, 2).Dedicated systems however have the 
disadvantage ot inflexiblityto any change in rendering options or object sizes 
(also the costs are high). Other systems make use of high performance 
general purpose machines, which are always very expensive and notalways 
suitable. This explains the reason for TNO-FEL to apply a system of 
programmable (low cost) processors operating in parallel. Prototype data for. 
the voxel processor was obtained from an experimental Confocal LASER 
Scanning Microscope (CLSM). The CLSM can be focussed on several 
consecutive layers of the object, producing a slice of data for each layer. A 


“slice typically consists of 256256 volume elements (voxels), with an intensity 


resolution of 8 bits per voxel (FIG. 4). The number of slices may vary, but a 
typical value is 32 to 256 (FIG. 2). This data structure is called the voxel space. 
Examples of application areas for the CLSM are medical-and biological 
research and inspection (eg. Integrated Circuits). Voxel space sizes depend 
largely on the sensor type, in CT scans for example it is possible to get 
resolutions of 512'512"128 with 12 bits per voxel, and these numbers still 
grow. The TNO-FEL voxel processor has the modularity to deal with varying 
size-and perlormance-demands. 


The 3-D Reconstruction 
The Voxel space consists of a block in 3-D space (FIG. 3). Displaying this data 
under different angles on a 2D screen involves a 3-D transformation of the 


object space into the display space (FIG. 4). Basically such a transformation 


vector). The matrices fora rotation around the X-, Y- 


angles AB and C respectively are : 
1 o o 
Ax= o cos A -sin A 
sin A cos A 
cosB o sinB 
Ry= o o 
-sin B o cos B 
cos C =sinG o 
Rz= sinC cos C 1 
o o 1 


These matrices a 
multiplication: 


concatenated into a single matrix before the actual 
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R= Bz" Ry Ax= 


(cB*cC) (sA"sB*cC-cB'sC) (cA*sB'cC-+sA*sC) 
(cB'cC) (sA”sB'sC+cB*sC) (cA"sB'sC-sA"cC) 
-sB (sA“cB) (cA°cB) 


('e'for cos, 's' for sin ). 


Suppose a resolution of 128 is used in X-,Y- and Z-direction with 1 byte per 
voxel. The voxel space then occupies 2 Megabytes. 2 Million vector-matrix 
multiplications of the kind described have to be performed to compute the 
correct orientation, Every vector-matrix multiplication consists of 9 muitiplica- 
tons and 6 additions. To compute a new projection therefore 18 million Mults 
‘and 12 million Adds would be needed. And this is just the pure computational 
load, without any overhead like instruction 

fetches etc. Fortunately, there are possibilities for a simplification. Since 
vector-matrix multiplication is a linear operation and basically all ofthe voxel 
coordinates have to be transtormed, it is not necessary to perform this 
multiplication for each and every coordinate. We may instead use previously 
calculated results to compute the next. In that case three simple additions are 
needed to step from one transtormed coordinate to the next. This method 
offers a considerable reduction in the computational load. 


The first step is to transform the unit-vectors from object-space into display- 
space, by multiplication with the previously calculated rotation matrix R. 


xy’ = o a 
nxz' 

nyx o 

nyy el 1 -R 
nyz’ o 

nx o 

nzy = o zig 
nz’ 1 


The transformed coordinates (x’,y’,z') of voxel (x,y,z) are now found with 


x nx’ nyx nzx' 
yl=e my ry” nyy tz” nzy 
z nxz' nyz’ nzx 


By simply changing only 1 dimension atthetime (.e. moving along the X-, Y-or 
is now generated by just three additions. The 
projection of the 3-D data onto a 20 surface (the screen) involves the hidden 
surface elimination: ‘distant’ voxels are obscured by ‘closer’ voxels if they a 
projected on the same location on the screen. Comparing the z-value of a 
new pixel with the z-value ofthe pixel already present on that screen location 
(Z-buffer algorithm), is avoided by traversing the voxel space in a back-to- 
front direction. When generating the screen this way, new pixels can simply 
overwrite any old value (Painters algorithm). 

Several ways of rendering the transtormed data on the screen are possible, 
the available options are: 
a) Display the object's inter 
view). (Photo 1) 

b) Display the object's ‘distance’ trom the screen at each location, resulting in 
a realistic depth illusion. (depth shading ). 

©) Display the object's density at each screen location, (integrate function). 
d) Display an intensity related to the layer from which the visible voxel 
originated. (layer view’). (Photo 2) 


Z-axis) a new coordiné 


as seen from the selected orientation (front 
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©) Select a 'Volume-Of-Interest within the available voxel space (this volume 
must be block-shaped). Through this option uninteresting or disturbing parts 
ofthe voxel image may be ‘peeled away’. (Photo 3) 

1 Selecta cutting plane through the object; voxels in ront of this plane will not 
be visualized. This option will create a cross-section through the object after 
rotation. (Photo 4) 

q) Select a threshold; voxels with a value below this threshold will become. 
transparent. 

h) Editand select different colour look-up tables. This feature enables the use 
of pseudo-colours or grey-scale transforms for certain intensity values, 
thereby increasing the visibility of interesting areas. 


The original images from the scanning device tend to be noisy in many cases, 
so noise filters af 


needed. Further image analysis operations (edge 
detectors etc.) are also provided. Currently implemented 3D image proces- 
sing algorithms are : 

- Mean filter. 

- Sobel and Roberts edge detectors. 

- Laplace filter. 

- Median filter. 

These filters are based on their 2D counterparts and operate on a (3°3°3) 
space. 


Parallel Processing. 

Computer applications tend to need increasing amounts of processing 
capacities. Single processor systems are reaching the limits of performance 
improvements. It is obvious that using more processors running in parallel 
should provide (theoretically) unlimited power. Many existing multi-proces- 
sor systems use à common communications channel (the bus) for intercon- 
nections. With a growing number of processors the bus capacity becomes a 
bottleneck for system performance. Communication bandwidth of the net- 
work should be increased also when processors are added. Providing 
processors with direct (point to point) connections for all data exchange will 
supply this increased bandwidth. 


Several classes of multi-processor systems may be defined. A common way 
to distinguish classes is between SIMD (Single Instruction stream Multiple 
Data stream) and MIMD (Multiple Instruction stream Multiple Data stream } 
type parallelism. In SIMD parallelism each processor in the network will 
execute the same instruction (synchronously) on different data. Array pro- 
cessors fallin this class. Examples are image processing applications where 
each processor performs the same filter operation on a different part of the 
image. When using MIMD parallelism processors can all be running different 
programs, possibly sending results to others when they are finished. 
Examples are pipelined systems or multi-user applications. 


Many existing sequential programs could benefit rom being able to perform 
more than one action atatime. Itis however generally not trivial to implement 
a parallel program on a processor network. Problems arising are: 
-_Decomposing the problem in a number of processes running in parallel. 
- Allocate processes to processors and select the network topology. 
-_Load-balancing the processors. 

-_Distributing data across the processors. 

- Efficient inter-processor communication. 

-_Synchronization between processors. 

-_Debugging the software. 


The INMOS T800 Transputer is a computer-on-a-chip, containing a 32 bit 
RISC ALU, a 64 bit Floating-Point Unit, memory and four high-speed 

(1.5 MByte/s) input/output links for point-to-point communication 

(Fig. 8, Ref. 3). The Transputer was specifically designed for efficient 

a high performance component (1OMIPS, 1.5 


parallel processing : it 
MFLOPS), with an on-chip process scheduler and low-overhead communi 
cation facilities. A network of Transputers may be constructed by connecting 
them via links. Each Transputer in a network has (private) local memory to 
store program and data. Transputers 

may be programmed in high level languages like PASCAL, FORTRAN or C. 


These languages must have facilities added to implement the special 
features of the Transputer (processes running in parallel, communication 
etc). OCCAM is a language that was created by INMOS to describe parallel 
processing and communication via channels (Ref. 4). In fact the Transputer 
may be considered a hardware implementation of OCCAM. 

Transputer versions without the floating-point unit are also available : the 
T414 (32 bit) and the 7212 (16 bit) 


Transputer networks belong to the MIMD class of parallel processing 
systems, all nodes in a network are basically independent units, communi- 
cating and synchronizing only 

when necessary. A MIMD network is the most flexible solution to parallel 
processing, since part of the network may actually be operating in SIMD- 
mode . At TNO-FEL, research has concentrated on the Transputer as the 
computational element in parallel processing applications, because of its 
useful features, high performance and software support. 


Parallelism may be accomplished in 3D image processing by splitting up the 
‘computations in either display space or in object space : 

Display space parallelism impliesthat each processor is assigned toa certain 
area ofthe final image (e-g.a number of scanlines). Since views ofthe rotated 
voxel image will be generated, this solution means that each processor must 
have access to the complete voxel space. 

Complete access is possible when a voxel image copy is stored in each 
processor (large memory requirement) or alternatively, processors could 
request voxel data elements when needed from a central store (communi- 
cation overhead). Load-balancing may be a problem, since the most 
‘computation intensive parts in the display-space will shitt according to the 


rotation angie. Ray-tracing is a typical example where parallel processing in 
display space is often used. The load-balancing can be tackled by 

implementing a processor farm construction. In this construction a controller 
part of the display) to each 
processor in the network as soon as this has finished work on a previous part. 
The controller does not need to know which processor will actually perform 
the job. Object space parallelism is based on access of a limited part of the 


original voxel image. This implies that each node is assigned to a section of 


process “farms out” a new piece of work (i.e. 


the voxel image, which is stored locally. A node will produce the contribution 

of the local data to the result. The actual result will be available after 

combining (merging) all the contributions. The advantages of this method 

over the previous one are : 

- Less memory requirement. 

- Fast access to the (local) voxel data. 

-_Good load-balancing, all contributions will need the same computation 
time, when the voxel data sizes are equal. 

Disadvantages are : the overhead of the merging operation and the fact that 

some data calculated by the nodes may not be needed in the final result. 


The advantages of the second method where strong enough to use object 
space parallelism in the voxel processor system. 


‘System Architecture 

Figure 5 shows a schematic representation of the voxel processor archi- 
tecture. Ellipses are used to represent modules running in parallel. Parallelism 
was achieved in several ways, the most important step is (as mentioned) to. 
divide the object space into eight (equally sized) subspaces (FIG. 3), where 
each subspace has been assigned to one Transputer. The modules will be 
explained in more detail below. 


The Controller 
In the controller the user-interface software and the graphics control unit 
(sending commands to the Graphics subsystem) are combined. The operator 
communicates with the ‘user-interface' part, which interprets and executes 
commands. The controller process is capable of sending commands to a 
Transputer based framegrabber, which may be used to acquire voxel data 
from some type of sensor. Alternatively, itis possible to read object data from 
subspace data, the object may be rotated and viewed interactively. The Voxel 
processor will produce a new image within 1 second after giving a command 
(or a 256°256*32 object). 

Continuous rotation is possible, since the subspace transformation and the 
may run in parallel. The resulting images can be stored on disk, and read in 
again at a later time. 


The Subspace Processor 
This module performs the object transformation and generates a partial result 
for its subspace. A subspace result will be of size 256*256 for an object of 
256°256"32 voxels, while the complete resulting image will be 512512 pixels. 
The dimension (D) of a subspace result is easily derived from the Voxel 
data-base dimensions (DX, DY, DZ) : 
D — SORT((DX? + DY? + DZ) ) 

A subspace partial result represents the intensity value for each pixel on the 
screen, except for the ‘integrate’ function, in which case a voxel count will be 
produced. The subspace data (the voxels) are loaded only once for each new 
object and will not be changed during the transformations. The Transputer 
will begin processing its data after receiving a command, which includesthe 
transtormed unit vectors and the selected type of rendering (e.g. front view, 
depth shade etc). Besides performing the voxel image transformation, this 
module is also used for the 30 image processing operations. For this end, 
memory is reserved to store both the original voxel image and a filtered 
version. 


The Merger 

All partial results must be combined (merged) into the complete resulting 

image. This result is transterred to the controlling process where it will be 

stored and displayed. The 'merger' process receives eight 2D results {romthe 

subspace processors. In order to combine the partial results in a correct way, 

the merger needs some additional data. This data consists of : 

a) A subspace offset. The offset is based on the x and y ccordinates of the 
subspace's transtormed origin. This value is needed to place the subspace 
result on the correct position in the final image (FIG. 6). 
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b) Asubspace priority. The priority is based on the z-value ofthe subspace's 
transformed origin. The lowest priority is for the subspace with the greatest 
distance from the viewer. The partial results of this subspace will be 
obscured by any subspace result of a higher priority (FIG. 7). 
The merging operation is mainly performed with the 20 block-move 
instruction (ORAW2D) of the T800 Transputer, which can be used when the 
subspace results are combined into the final image in order of increasing 
priority (the final image is initalized to zero first). The DRAW2D can not be 
used for the ‘integrate’ function, in which case the numbers in the subspace 
results corresponding to the same pixel have to be added. 


The Graphic subsystem 
This unit is used only for controlling a framebuffer in order to display the 
resulting im: 


Implementation Remarks 

- Voxel coordinates are represented using an INT32 during transformation 
time, This INT32 is in fact a fixed-point real (16 bit integer part, 16 bit 
traction). The accuracy is sufficient for this application and the performance 
is slightly better than when using REAL32. 

-_The object is translated to the centre of the screen, independent of the 
object's orientation. 


- Whenever possible, special processes were assigned to communication in 
order to achieve maximum efficiency of the Transputer Links. 

= A communication layer was integrated into the system. This layer provides 
data and command transport to all processes, and it is also capable of 
sending (debug) messages from each process to the operator screen. 

- The system is very flexible in the dimensions of the objects that are to be 
transformed. Basically the only limitation is the memory size of each 
Transputer (currently 1MB). At the moment these dimensions (and a few 
derived values) are declared in a library. Changing this library and 
recompiling the software will automatically generate a new version. (N.B. 
The object dimensions do not have to be a power of two). Some other 
possible sizes which will give the same performance are : 128*128*128, 
256°256°32 or 64°128°256, 

- Because of the modular set-up, itis very easy to trade-off system 
performance against cost (a version with 4 subspace processors is also 
built). 


Hardware 
The Voxel processor is built up entirely with off-the-shelf hardware. Each 

processor board offers two T800's with 1MByte of memory each. Other 
boards used, are the Display System with a T800 and 1MByte of video-ram 
and finally a framegrabber with an on-board T800. Physically the system 
consists of a 19” cabinet with 7 single euro-sized boards installed. The host 
system in the Voxel processor is an IBM-AT. All the program code was written, 
in OCCAM. Forthis application, itis not strictiy necessary to use T800's for all 
processing modules (few floating-point operations are needed and only the 
merger uses block-move: 
over-all system performance, 


However, their higher link-speed does increase 


Current Activities 

Work on the Voxel processor prototype is continued in a number of areas : 

a) Addition of more 3D image-processing algorithms. An important feature 
will be the computer assisted image segmentation (region growing) to 
select interesting areas in the voxel image. 
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b) Implementation of 3D geometrical measurements. For medical- and 
biological- imaging geometrical data is very important. Surface computa 
tions, distances and volume measurements have to be applied to the 
objects in the voxel space. 

c) Increase system performance by further code improvement and 
architecture optimization. For larger voxel space sizes a system with 
16 Transputers will be developed. In this larger system the architecture will 
be changed to atree structure. The advantage of a tree over a pipeline isin 
the shorter average length of the communication path between the PE's 
and the merger. 

d)_ implement the computation of statistical level information over (part of) 
the voxel data. Besides for user inspection, this has to be available to 
specific image processing functions like automatic thresholding, 
histogram equalization or edge detection. 

e) investigate (voxel) data-compression, determin 
times and implications on transform algorithms. 


ects on data transport 


f_Feasibility study on stereoscopic display facilities. 


Conclusions 
The Voxel processor is a successful demonstration of the performance 


improvement and flex 
that at least in some applications transputer-type parallel processing may be 
a good alternative for either supercomputers or dedicated hardware. Transpu- 


ty that parallel processing can deliver. It is shown 


ters have proved to be a very powerful tool. The development of the system 
software was nottrivial but the clear representation and support of parallelism 
that OCCAM offers helped a lot. 


The key features of the developed Voxel processor are : 

- Fast, interactive system. Typical rendering speeds are 1 sec. for 2 Mbyte 
voxel images. The speed may be increased by using more processors. 
—_Highly modular and easily adaptable software. The prototype is a general 

purpose framework for 3D image processing. 
- Low-cost, small-sized off-the-shelf hardware. Transputers 
purpose processors and the system may also be used for other 


re general 


(computational intensive) applications. 
- Flexible performance (linear cost/performance function). 
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Fig. 8 _T800 Block Diagram. 
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TRANSPUTERS, PARALLEL REKENEN IN EMBEDDED SYSTEMEN TEN BEHOEVE VAN 
BEELDCOMPRESSIE VOOR RUIMTEVAARTTOEPASSINGEN 


Ir. M.H.J.B. Versteeg 
Nationaal Lucht- en Ruimtevaartlaboratorium 


Transputers, parallel processing in embedded systems for image compression used in space applications. 
Within the METEOsat DISsemination (METEODIS)-project Nationaal Lucht- en Ruimtevaartlaboratorium (NLR) 
develops under contract with European Space Operations Centre (ESOC) and European Space Technology 


Centre (ESTEC) a system that demonstrates the feasibility of the use of compression and eneryption 
within the operational METEOrological SATellite (METEOSAT)-system. The compression function is used to 
iner; 


se the amount of meteorological data that can be disseminated to the users. 
In the METEODIS-system the compression and deconpression functions are performed by programmable 
units. In order to perform these functions at the required speed a powerful multí processor system is 
required, Within the METEODIS-project these functions are realized by two times four Transputers. The 
Transputer is a single-chip microprocessor with a Reduced Introduction Set Computer (RISC) architect- 


ure intended for the use in multi-processor systems. 


1_Introductie 

Het NLR verricht al een aantal jaren onderzoek naar 

datacompressie-methoden voor gebruik in de lucht- en 

ruimtevaart. Van de recente projecten kunnen de volgen- 

de genoemd worden: 

= Van 1984 t/m 1986 werd 
Decompression of Imaging Sensor Signals (CADISS) 


Compression and 


ontwikkeld. Dit is een prototype van een ruimte- 
waardig te maken multi-processor systeem voor com- 
pressie en decompressie van satellietdata. 

-__In 1985 is een onderzoek verricht in opdracht van 
ESTEC naar de mogelijkheden tot compressie van de 
beelddata van de METEOSAT satelliet. Het bleek 
mogelijk om de METEOSAT-beelddata met een factor 
twee te comprimeren zonder dat er bij decompressie 
fouten optreden ("lossless compression”). 

Een vervolg op dit onderzoek is het METEODIS-project. 

In dit project wordt in opdracht van ESTEC en ESOC een 

demonstratiesysteem gebouwd dat de haalbaarheid van 

beeldcompressie en encryptie binnen het raamwerk van 
het operationele METEOSAT systeem aantoont. 

Voor de uitvoering van de compressie en decompressie 

Functie worden in dit demonstratie systeem multi-proces- 

sor Transputer systemen gebruikt. 


2 Transputers 


2.1 Multi-processor systemen 
Aan computersystemen kunnen eisen worden opgelegd met 


betrekking tot de tijd waarbinnen de verwerkte infor- 
Vaak kan, 
steeds sneller wordende hardware, 


matie beschikbaar moet zijn. ondanks de 
niet aan deze eisen 
worden voldaan bij het toepassen van een systeem met 
een enkele processor. Om de verwerkingssnelheid van een 
systeem te vergroten kunnen meer processoren worden 


toegevoegd. 


Een snelle communicatie tussen processoren is mogelijk 
wanneer alle processoren in een systeem toegang hebben 
tot een enkel geheugen. Deze toegang tot dat centrale 
geheugen vormt echter al snel een ‘bottle-neck' in een 
systeem. Bij een aantal processoren zal namelijk de 
gemeenschappelijke bus verzadigd raken en het toevoegen 
van extra processoren heeft dan geen nuttig effect meer 
op de rekenprestaties. Wanneer dit punt bereikt wordt, 
is natuurlijk afhankelijk van het te berekenen probleem 
en het gebruikte algoritme. 

Een oplossing hiervoor is dat elke processor toegang 
heeft tot een eigen geheugen terwijl een ander communi- 
catiemedium gebruikt wordt voor het uitwisselen van 
gegevens tussen de processoren. Dit is de weg die in op 
Transputers gebaseerde systemen gevolgd wordt. 

Voordat de Transputer verder besproken wordt, zal eerst 
de taal aan de orde komen die de basis vormt voor het 
model van de parallelle processen, zoals dat op de 
Transputer geïmplementeerd is. 


2 De programmeert: Occam 

Software voor multi-tasking systemen kan met behulp van 
conventionele programmeertalen geschreven worden. De 
afzonderlijke processen worden dan met losse program- 
ma's beschreven, die met behulp van bijvoorbeeld com- 
municatieprimitieven informatie kunnen uitwisselen, 
Deze communicatieprimitieven kunnen beschikbaar zijn in 
de vorm van losse routines, maar deze kunnen ook in de 
taal zijn opgenomen. Deze programmeertalen blijven 
echter in beginsel sequentiële programmeertalen (bij- 
voorbeeld Pascal, of C met een real-time kernel). 

Meer geïntegreerde oplossingen zijn bijvoorbeeld te 
vinden in Concurrent Pascal en Ada, waarin speciale 
structuren gedefinieerd zijn voor communicatie en syn- 
chronisatie tussen de processen. 


In Occam is het concept van parallelle processing 
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op een basisniveau ingevoerd (Pountain Ref. 3, May Ref. 
4). Ieder statement in een Occam programma heeft de 
status van een op zich zelf staand proces. Processen 
kunnen worden samengevoegd tot grotere eenheden met 
behulp van "constiuctors". De belangrijkste construc- 


tors zijn de “SEQ" en de "PAR": 


SEQ: De binnen de "SEQ" constructor vallende processen 
worden 


quentieel afgewerkt, dit komt overeen met 
De "SEQ" is pas 
r het laatste, en daarmee alle, 


en normaal equenti, 


1 programm 


voltooid wann: 


statements uit de "SEQ" voltooid zijn. 

PAR: De binnen de “PAR” constructor vallende processen 
worden parallel uitgevoerd. De "PAR" is pas vol- 
tooid wanneer alle processen binnen de constructor 
voltooid zijn, 

De toegang tot variabelen binnen een constructor is ook 

op het mogelijk parallel verlopen van processen afge- 

stemd: 

SEQ: Het gebruik van variabelen binnen een "SEQ" koat 


overeen met een sequentiële programmeertaal; alle 


globale variabelen mogen gelezen en beschreven 
worden. 

PAR: Bij toegang tot variabelen binnen een "PAR" con- 
structor moet onderscheid gemaakt worden tussen 
twee gevallen: 

-__ variabelen die binnen een "PAR" door één pro- 
ces beschreven worden zijn daarmee voor andere 
processen ontoegankelijk. 

- variabelen die alleen gelezen worden zijn voor 
alle processen binnen een "PAR" toegankelijk. 

Met deze beperking worden synchronisatieproblemen 

vermeden. 

Voor de communicatie tussen processen bestaat binnen 
Occam het zogenaamde "channel": een eenrichtings-com- 
municatiemedium. Een proces kan lezen van of schrijven 
naar een "channel" met behulp van speciale assignment 
statements. De data-transfer over een “channel” is 
synchroon; dat wil zeggen dat de transfer plaats vindt 
als beide processen gereed zijn voor de communicatie- 
actie. 

Occam sluit hierbij echter “dead-locks" niet uit. Met 

twee kanalen kan eenvoudig een statische “dead-lock” 

gecreëerd worden. 


2.3 _Transput 

De Transputer is een single-chip microprocessor die 
speciaal ontwikkeld is om het Occam parallel-processing 
model efficiënt te kunnen uitvoeren. De Transputer be- 
staat uit een 32-bits processor (de T212 bevat een 16- 
bits processor) met een RISC-architectuur. Qua presta- 
ties kan de Transputer zich goed meten met andere mo- 
derne chips (Fig. 1) (1988 Ref. 1). 

Om het Occam multi-tasking model te ondersteunen bevat 
de Transputer een scheduler die direct in microcode is 


vastgelegd. Hierdoor kan een proceswisseling zeer snel 


uitgevoerd worden (minder dan 1 ys). Het gevolg hiervan 


is, dat er geen keuze meer mogelijk is tussen verschil- 


lende scheduling-algoritmen. 


PROCESSOR 


ON-CHIP 
STATIC RAM 


MEMORY 
INTERFACE 


Fig. 1 Overzicht Transputer 


In een Occam-programma bestaat er één beschrijvingsme- 
thode voor “channels”. De uitvoering van deze "chan- 
nels" is afhankelijk van de verdeling van de processen 


en de links over de beschikbare Transputers: 


- In het geval dat op een enkele Transputer ver- 
schillende processen parallel worden uitgevoerd 
zullen de "channels" tussen deze processen in het 
geheugen van de Transputers geplaatst zijn. 

- Een Transputer bevat ook een aantal externe 
“links” , deze seriële verbindingen worden ge- 
bruikt als “channels” tussen processen die op 
verschillende Transputers worden uitgevoerd, 

De toekenning van processen aan processoren in een 

systeem kan in een late fase van de software-ontwikke- 

ling worden uitgevoerd, omdat de configuratie informa- 
tie los staat van het eigenlijke programma. Hierdoor is 
het ook mogelijk om, met een beperkte prestatie, ont- 
wikkelde software op één of enkele Transputers te tes- 
ten wanneer het benodigde multi-Transputer systeem nog 
niet beschikbaar is. Op dit moment zijn er nog weinig 
hulpmiddelen voor het verdelen van processen over de 
verschillende Transputers in een systeem. De meeste 
huidige Transputers bevatten vier seriële "links", die 
onafhankelijk van de processor data over de "links" 
kunnen verpl 


tsen (Direct Memory Access (DMA) trans- 
fers). De datatransfer-snelheid over de "links" be- 
draagt maximaal 20 Mbit/s; dit resulteert in een 
effectieve transfer-snelheid van maximaal 1.7 MByte/s, 
Het interne geheugen van de Transputers is bij de 
huidige types slechts maximaal vier KByte groot. Vaak 
is meer geheugen vereist voor toepassingsprogramma's en 
data. Het geheugen van de Transputer kan worden uitge- 
breid met extern geheugen; de hiervoor benodigde timing 
signalen inclusief de eventueel benodigde refresh-sig- 


nalen worden al door de Transputer zelf gegenereerd. 
Hierdoor blijft een enkel processing-element eenvoudig 
en kan bestaan uit slechts een tiental chips. 

Sommige typen Transputers bevatten nog extra functies. 
Als voorbeeld wordt hier een floating-point-eenheid 
genoemd. Deze maakt het mogelijk dat de Transputer ook 
numerieke berekeningen met hoge snelheid uitvoert. 


2.4 Topologie 
Voor het uitvoeren van algoritmen kunnen verschillende 


topologiën van proce 


n worden gebruikt. Deze proces- 


topologiën moeten vervolgens in de uitvoeringsfa 
worden afgebeeld op hardware structuren. 


Wanneer 


n algoritme in een 


ntal Occam-proc 


geïmplementeerd moet worden, bestaan er een groot aan- 
tal mogelijkheden tot opdeling. Een aantal voorbeelden 
wordt hier genoemd. Het eerste en het vijfde voorbeeld 
gaat uit van een opsplitsing in deel functies ("func- 
tional partitioning"), terwijl de andere voorbeelden de 
te bewerken data verdelen over een aantal processen 
("data partitioning”). 
1) pipe-line: 
Een aantal processen voert ieder steeds een ver- 
schillende fase van een bewerking parallel uit. 
Wanneer alle processen hun data bewerkt hebben 
worden de datapakketten één proces doorgeschoven 
(Fig. 2a). 
De verschillende gekozen stappen van de totale 
bewerking moeten wel een vergelijkbare verwer- 
kingstijd nodig hebben, anders zijn elementen van 
de pipe-line niet continu bezet. 
2) parallel processing: 
Een aantal processen voert identieke bewerkingen 
parallel uit. Wanneer de bewerkingstijd onafhan- 
kelijk is van de ingangs-gegevens zullen de paral- 
lelle processen evenveel tijd nodig hebben voor de 
processtap (Fig. 2). 
Wanneer de invoer of de uitvoer vanuit of op één 
punt terecht moet komen, zijn er processen nodig 
die de gegevens uitsplitsen of verzamelen. Gezien 
het geringe aantal links per Transputer kunnen 
maximaal drie uitgangen worden aangestuurd. 
Wanneer meer parallelle processing vereist is om 
de benodigde prestaties te bereiken, moet het uit- 


menvoegen in verschillende trappen 


gebeuren. 


3) _ processor array: 


De processoren kunnen in een één-, twee- of drie- 


dimensionaal netwerk verbonden worden, wat bij- 
voorbeeld overeenkomt met een logische rangschik- 
king van de ingang: 


of uitgangsgegevens. Als 
voorbeeld valt hier te denken aan beeldbewerking. 
De processoren kunnen hierbij gerangschikt worden 
in een twee-dimensionaal array (Fig. 2e). Dit is 
vooral aantrekkelijk wanneer de uit te voeren be- 
werkingen voornamelijk een lokaal karakter hebben. 


4) farm 
Elke eenheid voert een volledige bewerking uit 
maar bevat ook nog twee doorgeefprocessen (Fig. 
2d). 

Deze configuratie is vooral geschikt voor bewer- 
kingen waarvan de verwerkingstijd sterk afhanke- 

Bij deze * 


lijk is van de ingangs gegevens. arm" 


zconfiguratie zullen alle processoren steeds 
continu bezet zijn. 

5) hiërarchische structuur: 
Sommige algoritmen lenen zich voor uitvoering in 
een hiërarchische structuur (Fig. 2e). Op laag 
niveau moeten de bewerkingen dan een lokaal ka- 

ds 


rakter hebben terwijl op de hogere niveaus st 
weer ingangs-informatie samengenomen wordt. 
Andere mogelijkheden benutten een specifieke topologie 
om bijvoorbeeld de procesconfiguratie aan te passen aan 
de ordening van de data of om een extra betrouwbaar 


systeen te verkrijge: 

-__redundant systeem: 
De topologie van een bijvoorbeeld lineair array 
van Transputers kan zo gekozen worden dat bij de 
uitval van één of enkele Transputers het gehele 
systeem nog steeds blijft werken (Fig. 2E). De 
prestaties van het gehele systeem zal dan wel te- 
rug lopen, maar de vereiste functie kan nog steeds 
verricht worden. Dit vereist een software-struc- 


tuur die dit ondersteunt. 


Om am 


a) Pipeline bewerking 


UIT - 


b) Parallel bewerking 


ee. 


ec) Twee- dimensionaal netwerk 
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d) ‘Farm’ bewerking 


e) Hierarchische bewerl 


f) Redundant lineair netwerk 


Fig. 2 Proces-topologiën 


Binnen het Transputer multi-tasking systeem kan voor de 

processen zonder beperking een topologie gekozen wor- 

den. Voor de hardware zijn echter beperkingen aanwezig, 

omdat iedere Transputer maar een beperkt aantal "links" 

bezit. Er zijn dan twee oplossingen: 

- Verschillende logische links kunnen via een enkele 
fysieke link gemulciplexed worden. 

- Een enkele logische link kan over een aantal fy- 
sieke links gerealiseerd worden. 

Deze oplossingen gaan ten koste van de bereikbare data- 

transfer snelheid. Voor zo hoog mogelijke prestaties 

wordt er vaak naar gestreefd om het netwerk van pro- 


ce: 


en zo op de hardware of te beelden dat één logische 
Link overeenkomt met één fysieke "link". 


3 METEODIS systeem 


3.1 _METEOSAT 

De METEOSAT satelliet is een meteorologische geostatio- 
naire satelliet die boven de nul meridiaan staat. In 
drie spectrale banden (visueel, waterdamp en infrarood) 
maakt deze satelliet ieder half uur een opname van de 


gehele zichtbare aardbol. Afhankelijk van de spectrale 
band heeft dit beeld een resolutie van 5000*5000 of 
250042500 beeldpunten. 

Ieder half uur wordt zo 37% MByte beeldinformatie ver- 
zameld. Continu wordt deze beeldinformatie naar het 
grondstation van ESOC in Darmstadt gestuurd (Fig. 3). 
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Fig. 3 Overzicht METEOSAT systeem 


Hier worden op een main-frame geometrische en radio- 
metrische correcties op de beelddata uitgevoerd. Een 
selectie van de beelddata wordt vervolgens via de 
METEOSAT-satelliet, die dan als communicatiesatelliet 
fungeert, naar de gebruikers verzonden. 

Niet alle verzamelde beeldinformatie kan naar de ge- 
bruikers verzonden worden, omdat de capaciteit van het 
disseminatie-kanaal beperkt is tot 166.6 Kbit/s. Een 
deel van de capaciteit wordt ook nog gebruikt voor het 
versturen van andere produkten naar de gebruikers, zo- 
als beelden die door de Amerikaanse Geostationary 
Operational Environmental Satellite (GOES) satelliet 
verzameld zijn en van de METEOSAT-data afgeleide pro- 
dukten. 


3.2 METEODIS 

In het verleden heeft het NLR onderzocht hoe de 
METEOSAT beelddata kunnen worden geconprimereerd. Van 
gebruikerszijde is hierbij altijd geëist dat compressie 


alleen interessant is, als er na reconstructie geen 


fouten overblijven ten opzichte van het oorspronkelijke 
beeld. Een mogelijkheid tot een gemiddelde compressie- 
factor van ruim twee werd gevonden in het MEANDER-com- 
pressie-algoritme. De uitgevoerde studie betrof vooral 
de theoretische mogelijkheden tot datacompressie. 

Het METEODIS-project zal de haalbaarheid van compressie 
operationele METEOSAT-systeem 


(Börger 1988). Het METEODIS-systeem is een demonstra- 


binnen het aantonen 
tiesysteem, dat mogelijk kan uitgroeien tot een com- 
pleet operationeel systeem. Naast de compressiefunctie 
zal ook een eneryptiefunctie gerealiseerd worden, maar 
deze zal hier verder niet besproken worden. 

De compressie- en deconpressie-functies van het 
METEODIS-systeem worden gerealiseerd in twee embedded 


systemen (Fig. 4): 
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Fig. 4 METEODIS demonstratie systeem 


- Het eerste systeem met de compressiefunctie, wordt 
verbonden met de computers in Darmstadt en zal de 
beelddata comprimeren voordat een beeld wordt 
verstuurd naar de gebruikers, 

- Het tweede van het 


systeem vormt een prototype 


embedded-systeem dat iedere gebruiker met zijn 

operationele ontvangstsysteem moet verbinden. Voor 

de demonstratie wordt een ontvangstsysteem in 
Darmstadt met deze eenheid uitgerust. 

Beide systemen bevatten geen andere interfaces dan de 

bovengenoemde. De data die gecomprimeerd moeten worden 


zullen een indicatie bevatten die aangeeft dat deze 


functie geactiveerd moet worden. Deze indicator wordt 
ook meeverzonden met de data over de satellietverbin- 
ding, zodat het decodeersysteem aan de decompressie- 


functie kan starten. 
Voor de gebruiker van de METEOSAT-beelden is dit gehele 
systeem transparant. Het enige dat hij/zij merkt is dat 
de beelddata in kortere tijd verzonden kan worden. 

Na compressie is een groot deel van de redundante 


informatie uit de beelddata verwijderd. Hierdoor zijn 


deze data gevoeliger voor transmissiekanaalfouten. Als 
kanaalfouten de verzonden data aantasten, zullen de 
effecten op de beelddata na decompressie ook veel beter 
zichtbaar zijn: een enkel verminkt bit kan nu een deel 
van een beeldlijn verstoren, terwijl zonder compressie 
slechts een enkel beeldpunt zou zijn aangetast. 

Om ervoor te zorgen dat de kwaliteit van de beelddata 
die de gebruiker bereikt niet achteruitgaat, wordt een 
Forward Error Correcting (FEC) code toegepast. 

Bij metingen van het transmissiekanaal bleek dat de 
gevonden kanaalfouten konden worden geclassificeerd als 
dat met een 


Als er bij- 


random single bit errors. Daaruit volgde 
eenvoudige FEC-code volstaan kon worden. 
voorbeeld sprake was geweest van burst errors, bit 
insertions en/of bit deletions, was een complexere FEC 
nodig geweest. Deze code voegt gecontroleerd enige re- 
dundantie (» 5 #) aan de verzonden data toe, waardoor 
aan de ontvangende kant een deel van de opgetreden ka- 


naalfouten hersteld kan worden. 


4 Algoritmen 


&.1 Compressie 
Voor de compressie van de METEOSAT-beelddata wordt het 


MEANDER-algoritme gebruikt. Met dit algoritme kunnen 
beelddata gecomprimeerd worden en vervolgens weer fout- 
loos gedecomprimeerd. Foutloos wil hier zeggen dat er 
dan geen verschil is tussen het gedecomprimeerde beeld 
en het origineel. Voor deze klasse van compressie-algo- 
ritmen ("lossless") is de behaalde compressiefactor 
echter afhankelijk van de informatie-inhoud van de data 
(Fig. 5). Aangezien deze over het beeld varieert, kan 


het best worden gesproken over de gemiddelde compres- 
siefactor. In het geval van de METEOSAT-beelden kan 
voor alle drie spectrale kanalen een gemiddelde com- 
pressiefactor van ruim twee gehaald worden. 

Het algoritme werkt op stukken van beeldlijnen en 
bestaat uit de volgende stappen: 

Verschillen bepalen (DPCM): 
Van opeenvolgende beeldpunten worden de verschil- 


len bepaald. Omdat er sprake is van correlatie 
tussen opeenvolgende beeldpunten, zullen deze ver- 
schillen voornamelijk uit kleine getallen bestaan. 
De waarde van het eerste beeldpunt van een lijn- 
stuk wordt direct verzonden. 
Indelen in klassen: 
De verschillen worden in klassen ingedeeld, die 
aangeven hoeveel bits benodigd zijnom de ver- 
schillen te coderen. De klassen worden zo gekozen 


dat het verschil tussen opeenvolgende klassen 
maximaal één is. 

Klassen coderen: 
De verschillen tussen opeenvolgende klassen worden 
per drietal 


gecodeerd en verzonden; de eerste 


klasse wordt weer direct verzonden. Voor het co- 


deren van deze drietallen wordt een Huffman-code- 
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ring gebruikt, de hiervoor gebruikte coderingsta- 
bel is afhankelijk van de soort (spectrale kanaal) 
beelden. 
Verschillen coderen: 

De verschilten worden gecodeerd met het aantal in 
de klasse gespecificeerde bits. Een kleine winst 
word nog geboekt door verschillen waarvan bekend 
is dat deze optimaal gecodeerd kunnen worden, met 
een bit minder te coderen. 

Het eerste beeldpunt, de gecodeerde klassen en de geco- 

deerde verschillen worden vervolgens samengevoegd en 


verstuurd. 


COMPRESSIE FACTOR VOOR HET GEHELE BEELD 2.88 (SPECIFIEKE GEVAL) 
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Fig. 5 Compressie factor afhankelijk van de beeld 
informatie 


Het compressie-algoritme codeert stukken beeldlijn 


met een vaste lengte. Hierdoor ontstaan gecomprimeerde 


egmenten met een variabele lengte. Het METEOSAT-trans- 
missieformaat gaat echter uit van frames met een vaste 
lengte. De segmenten met een variabele lengte worden, 
tezamen met een identificatie, inde frames verpakt 
(Fig. 6). In elk frame wordt nog een aantal ruimtes 
vrijgehouden voor de nog toe te voegen FEC code. 

Om ook na korte onderbrekingen van een uitzending het 
begin van gecomprimeerde segmenten te kunnen vinden 
wordt er per frame een pointer naar de start van het 
eerst volgende gecomprimeerde segment toegevoegd. Deze 


pointer verzorgt de synchronisatie van de verzonden 
segmenten. De frames met een vaste lengte bevatten een 
hardware synchronisatiepatroon dat door de ontvanger 
gedetecteerd wordt en ervoor zorgt dat het begin van de 


frame in een transmissie gevonden kan worden. 
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Fig. 6 Verpakken van variabele lengte segmenten in 
vaste lengte frames 


4.2 Foutcor! 


(FEC 
Om bij de ontvanger foutcorrectie mogelijk te maken 
wordt aan de te verzenden data een Forward Error Cor- 
rection (FEC) code toegevoegd. Aan de ontvangende zijde 
kan nu een deel van de opgetreden kanaalfouten gecor- 
rigeerd worden. 

De FEC code werkt op blokken data van een vaste lengte 
(171 bits), aan elk blok wordt door de FEC-code een 
aantal redundante bits toegevoegd. Deze bits zijn een 
soort 'pariteits'-bits, die bepaald worden uit de de- 
ling van de te versturen data met het FEC-generator- 
polynoom. 

Aan de ontvangende zijde wordt een overeenkomstige be- 
werking uitgevoerd. Er kan dan gedetecteerd worden of 
de ontvangen data correct (foutloos) is ontvangen. Als 
er tijdens het versturen van het blok één enkele trans- 
nissiefout is opgetreden kan deze met behulp van de 
redundante bits hersteld worden. De gekozen FEC biedt 
ook nog de mogelijkheid om te detecteren als twee bits 
in een verzonden blok foutief overgekomen zijn. 


5 Uitvoering 
Voor de uitvoering van de compressiefunctie binnen het 


METEODIS systeem is gekozen voor een oplossing geba- 
seerd op Transputers, waarbij de FEC functie in een 
Programmeerbaar Logic Device (PLD) is uitgevoerd. 

De volgende overwegingen hebben hierbij een rol ge- 
speeld: 

- Voor het compressie-algoritme ging de voorkeur uit 


naar een programmeerbaar systeem, zodat kleine 


aanpassingen in het algoritme nog aangebracht kon- 
den worden. Ook is het gehele compressie-algoritme 
zo complex dat een directe hardware uitvoering erg 
omvangrijk zou worden. 

- De gebruikte componenten moesten voldoende per- 
formance leveren om de bewerking bestaande uit de 
compressie en het FEC algoritme real-time (166,6 
Kbit/s) uit te voeren. 

Zowel een multi-processor systeem gebaseerd op de 
68000-familie (Versteeg 1987), als een multi-pro- 
cessor Transputer systeem kan deze taak uitvoeren. 
De processor eenheden bij een Transputer multi- 
processor systeem bestaan uit slechts een tiental 
componenten zodat het gehele systeem compact kan 


worden uitgevoerd. 


- Het moet eventueel mogelijk zijn om de compres- 
siefunctie later aan boord van een satelliet uit 
te voeren. De gebruikte componenten zouden dit 
niet bij voorbaat onmogelijk moeten maken. In op- 
dracht van ESTEC is een onderzoek verricht naar de 
mogelijkheid om ruimtewaardige Transputers te ver- 
krijgen. Een resultaat van dit onderzoek was dat 
deze kwalificatie mogelijk was en dat de in de 
Transputers gebruikte CMOS-techniek direct al goed 
bestand is tegen straling. 

=De deling die voor de FEC benodigd is, kan een- 
voudig worden uitgevoerd met behulp van een 
schuifregister met terugkoppelingen. Nadat het 


gehele te beschermen data- woord door dit schuif- 


register geschoven is, bevat het schuifregister de 


gewenste 'pariteits'-bits; deze worden dan aan de 


te verzenden data toegevoegd. 

De schuifregisters met terugkoppelingen kunnen 
all 
uitgevoerd. Een hardware-oplossing voor de FEC, 


n met veel moeite in een processor worden 


bestuurd vanuit de software, vereist slechts 
schuifregisters van negen elementen met een aantal 
terugkoppelingen. 

- Het NIR had enige ervaring met Transputers; op 
grond van experimenten werd verondersteld dat de 
conpressiefunctie met vier Transputers te reali- 
seren moest zijn. Mocht echter gedurende het 
METEODIS-project blijken dat dit aantal niet toe- 
reikend is om de vereiste prestaties te halen, dan 
kan dit aantal eenvoudig worden uitgebreid. 

De verdeling van de processen over de Transputers is 

niet eenvoudig vanwege de volgende feiten: 

- Een "functional partitioning” van het algoritme is 
moeilijk: de beschreven algoritmestappen kunnen in 
een aantal gevallen nog wel wat verder opgesplitst 
worden, maar het aantal Occam- 

processen blijft toch zeer beperkt. 

-___Een "data-partitioning" levert een ander probleem: 
omdat de hele compressie functie één uitgaande 
data stroom moet produceren, moet er ook sprake 
zijn van een enkel 'pack’-proces. 

In het METEODIS project is gekozen voor een "pipe-line” 

benadering (functional partittoning) voor de verdeling 

van de processen over de Transputers (Fig. 7), De 

Transputers voeren na elk; 


r de bewerkingen uit op de 
data, Als de keten uit veel deelprocessen bestaat kan 
een vergroting van de bewerkings snelheid eenvoudig 
bereikt worden door meer Transputers te gebruiken. Het 
langzaamste proces in de keten bepaalt nu de maximaal 
te behalen snelheid van de gehele keten. Om dan een zo 
hoog mogelijke verwerkingssnelheid te halen moet het 
langzaamste proces een eigen Transputer toegewezen 
krijgen. 

Nadat het langzaamste proces een eigen Transputer toe- 


gewezen gekregen heeft, kan een verdere versnelling nog 


op twee wijzen bereikt worden: 


- Het langzaamste proces wordt opgesplitst in een 


ntal deelprocessen die verdeeld worden over ver- 
schillende Transputers. 
- Twee Transputers worden ingezet om het langzaamste 
proces parallel te gaan uitvoeren. 
Het is bij het gebruikte algoritme niet eenvoudig mo- 
gelijk om de gehele bewerking in twee parallelle takken 
uit te voeren. De tijd-rovende 'pack'-bewerking die de 
gecomprimeerde segmenten met een variabele lengte in de 
transmissieframes verpakt moet door een enkel proces 
aan het eind van de keten worden uitgevoerd. Voor het 
huidige systeem wordt echter verwacht dat de gebruikte 
vier Transputers voldoende zijn om de vereiste snelheid 
te bereiken. 


Fig. 7 MEANDER compressie algoritme 


Als de doorvoersnelheid van het hele systeem nog 
verder verhoogd moet worden dan de nu vereiste 166,6 
Kbit/s, moet er echter gezocht worden naar andere op- 
lossingen. Mogelijkheden kunnen gevonden worden in: 

5 Verder onderzoek naar compressie algoritmen die 
mogelijk eenvoudiger parallelliseerbaar zijn, of 
die direct gebaseerd zijn op een parallel bewer- 
king. 

Het probleem is namelijk dat bij het implementeren 

van het MEANDER algoritme geprobeerd wordt een in 

beginsel sequentieel algoritme ineen parallelle 
structuur uit te voeren. 

- Parallel uitvoeren van delen van het MEANDER-algo- 
ritme. Een probleem hierbij vormt de ‘pack'-func- 
tie. Als dit parallel wordt uitgevoerd zal de ge- 
comprimeerde beelddata niet meer op volgorde 

verstuurd worden. Dit vereist dan weer extra in- 

spanning van de decompressiefunctie. 

Misschien ís het nog mogelijk om een deel van de 

‘pack’ functie, die veel schuifoperaties van lange 

reeksen bits over korte afstanden vereist, in 

hardware uit te voeren. Dit kan dan misschien in 
conbinatie met de hardware die gebruikt wordt voor 
de FEC-functie. 
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Gebruiken van de "packetized-telemetriestandaard” 
voor het versturen van data over het kanaal. De 
drie verschillende spectrale kanalen kunnen dan 
onafhankelijk gecomprimeerd worden en vervolgens 


op frame-basis worden samengevoegd. 


6 Conclusies 


Naar aanleiding van het gebruik van Transputers binnen 


het METEODIS project kunnen een 


intal conclusies ge- 


trokken worden: 
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De Transputer lijkt een geschikte component om als 
basis te dienen voor het maken van high-performan- 
ce dedicated systemen. Problemen die met behulp 
van parallelle algoritmen kunnen worden opgelost, 
kunnen met dedicated Transputer systemen met zeer 
hoge snelheid verwerkt worden. Bij geschikte pro- 
blemen kan het aantal Transputers naar wens worden 
uitgebreid om de vereiste prestaties halen, zonder 
dat dit leidt tot een bottle-neck in de communi- 
catie. 

Voor algemene toepassingen is 
moeilijk toegankelijk. 


Mogelijk wordt dit verbeterd door nieuwere 


de Transputer nog 


bestu- 
ringssystemen. Een mogelijk voorbeeld hiervan is 
het HELIOS-beheerssysteem, 
Transputers naar de gebruiker / programmeur als 


waar een ‘pool’ van 
een UNIX-achtig systeem gepresenteerd wordt. 
Occam biedt een mogelijkheid om parallelle algo- 
ritmen compact en duidelijk te beschrijven. 
Gebruikers raken ervan doordrongen dat binnen pro- 
gramma's sequentieel denken erg vanzelfsprekend 
is. 


Mogelijk bieden Occam en andere op parallel pro- 


cessing gerichte programmeertalen handvatten om te 


komen tot een directer parallel begrip van pro- 


blemen. 
- Het parallelliseren van beschikbare sequenti 
algoritmen levert vaak grote problemen op. 

Als de oplossing van een probleem mogelijk op 
parallel systeem moet worden uitgevoerd, dan 
dit direct bij de ontwikkeling van het 


moeten worden meegenomen, 


algori 
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